Ember 2.1 introduced a regression where all errors during a transition
were thrown, even when those errors had been handled in a route's error
action. This PR adds a test to identify the regression, and adds some
logic and state to identify errors that have been handled, and not
reraise them, while maintaining the desired behaviour of throwing errors
that aren't handled.

This is especially valuable in any application that tests error
handling. Since all errors were being thrown regardless of handling,
failed assertions were being registered by qunit, and it became
impossible to test application flow that entered the error hook.

Further details about this issue are here:
emberjs#12547

Remove leftover debugger

This addresses an issue where handled errors are still thrown

The added test passes on Ember 2.0. It fails on Ember 2.1 because even though
the error is not bubbled, the application throws the handled error.

This is contrary to what the documentation indicates.

Full details about this issue are here: emberjs#12547

This PR also adds a very naive implementation of how to flag an error as having
been handled and prevents reraising, while retaining the functionality of throwing errors
that aren't caught, or are bubbled from the application route

Make error checking methods a part of the router instance

Attach error caching methods to EmberRouter, and use guids for errors

Errors used as keys were just getting `.toString()`ed, so multiple
`Error`s or hashes would all have the same key. This update uses ember
`guidFor` to uniquely identify errors. Thanks for the help @rwjblue!

When creating a new promise, resolve it. Don't fork the promise

Tests expecting errors to bubble up, should bubble errors

This provides insurance that handled errors aren't swallowed